1. Field of the Invention
This invention is directed to the field of multicasting over a network, such as a network connecting multiple general-purpose and/or special-purpose computers such as telephones, and, more particularly, for a more reliable method of ringcasting.
2. Discussion of Related Art
In co-pending U.S. patent application Ser. No. 11/650,698, a method of multicasting via a ringcast is disclosed. In brief, the method disclosed therein is directed to ringcasting: a novel method of using a single logical, or application-level, connection in a packet-switching network (preferably based on TCP/IP protocols) to distribute real-time media content, such as an audio or video conference, to many recipients without using a centralized media server. The method disclosed in that application provides for establishing serial connections between the participants in a multicast, and then passing a signal from one participant to the next along the connections to distribute the content to every desired participant. The method offers the ability to distribute content, and particularly to distribute content in such a way as to meet the requirements for low-latency, real-time applications such as IP telephony audio/video conferencing, without the use of centralized (expensive) media servers to perform media functions such as mixing and multi-party distribution. The method also scales in multiple dimensions, e.g., each participant performs the same actions and uses the same number of (logical) network connections regardless of the number of participants in the session. The method for content distribution is intended to be used by applications that may have media distribution requirements for real-time and/or for low-latency, such as audio and video conferencing applications in which at least one of the media recipients is human, and that are loss-tolerant, i.e., the applications are mildly fault-tolerant in the sense that the applications perform effectively despite some content loss due to the dropping of packets during network traversal or during endpoint packet processing. For reference, IP telephones are often engineered to tolerate packet loss rates of between 1% and 10% while maintaining acceptable conversation quality as measured by some standard method.
Some applications, however, such as file-transfer applications which may transmit data files containing sensitive information, e.g., financial transactions, are loss-intolerant in the sense that they cannot recover from information loss which occurs if packets are lost during network transmission. For example, in a TCP/IP network, the internetwork-layer protocol, called the Internet Protocol (IP), makes a best-effort attempt to rout packets to their destinations but does not guarantee delivery of packets to their destinations. Packets may be dropped during transmission through a network if, e.g., a packet router queue overflows. Packet delivery guarantees (or lack thereof) are the responsibility of transport or transfer protocols used in layers above the IP layer. For example, at the transport layer immediately above the IP layer in the TCP/IP stack, two popular transport protocols are the User Data Protocol (UDP) and the Transmission Control Protocol (TCP). UDP does not guarantee packet delivery, whereas TCP does guarantee packet delivery. UDP and TCP are referred to as “unreliable” and “reliable” transport protocols, respectively. Both UDP and TCP are designed for unicasting, i.e., for transport of data between two hosts. If a networked application is loss-tolerant, it may use UDP, and in practice must use UDP if there is a low-latency requirement. Loss-intolerant applications may use TCP to ensure that the network delivers all packets transmitted between application hosts. Some loss-intolerant applications do not use TCP as the transport protocol because of concerns about scalability or overhead, in which case the application itself is responsible for reliability, i.e., detecting packet drops and recovering from them by, e.g., causing a re-transmission of any dropped packets.
Besides its loss tolerance (or intolerance) characteristic, an application may choose UDP or TCP depending on its latency requirements. For some applications with a low-latency requirement, such as voice and/or video conferencing between humans, TCP is not a practical option for reliability because the latency incurred from detection and re-transmission of dropped packets is often larger than application requirements. Hence, such applications typically use UDP as the transport protocol and additionally build in some degree of packet loss tolerance. Recall, though, that UDP is designed to support unicast data transport between two hosts, so in the case where data needs to be distributed simultaneously to multiple hosts, some additional mechanism, e.g., multicast or multiple unicasts, may be employed to accomplish the data distribution. The ringcast method of U.S. patent application Ser. No. 11/650,698 is appropriate for use as the media content distribution mechanism for these low-latency, loss-tolerant applications which include multiple participants.
Other multi-party applications, however, have a hard requirement for reliability, and would preferably use a reliable multicast to distribute content to multiple participants. Examples of such applications include multi-party collaboration, text chat, and notifications. Ideally, a reliable multicast protocol is available to distribute the content; however, a reliable multicast protocol has been elusive. The IETF has been developing the NORM protocol for reliable multicast, but it is an IP-level protocol and therefore in a TCP/IP network, the protocol must be implemented by the IP routers. Given that traditional (unreliable) multicast is often not available in commercial WANs, one can expect that the NORM protocol will similarly be largely unavailable. Furthermore, the NORM protocol is a one-to-many reliable multicast, i.e., only one participant may distribute content during each multicast; a many-to-many multicast is effected by having each sourcing participant separately perform a one-to-many multicast, which may be inefficient. Multi-party applications that need a reliable multicast for content distribution cannot depend on the network to provide it and therefore should implement an application-level protocol; however, no application-level, multi-party, reliable multicast protocol exists. The ringcast described in U.S. patent application Ser. No. 11/650,698 does not provide for reliability, but it is an application-level multicast that if modified to include reliability would be useful as a content distribution mechanism for loss-intolerant, multi-party applications. Thus, there is a need to ensure that participants in a ringcast receive all of the content distributed by the application.